回复#2 @osalee :

我也没什么好想法。

welcome!

回复#3 @简单 :

你是说移动版？

等我官网活跃度上来了再说吧。

回复#6 @osalee :

我记得一个空白的CI消耗的资源，跟我现在网站整个首页消耗的资源差不多，都要2ms，甚至更多，详细的没测试。

改标题虽然是个挺容易写的功能，但目前还没加入的打算。

标题毕竟不常修改，留着挂人用。

功能不大写起来却挺繁琐，有几百行吧，边界条件比较多。

回复#4 @wh669 :

可以

回复#4 @osalee :

啊对，还有其他性能更低下的框架，但是我没有针对哪些程序的意思，只是指出一个事实。

回复#2 @wh669 :

关键字是自动填充的。

有什么建议吗？

允

什么关键字？

或者说以后大概也不会有这个计划。

观察了一下一些有回复可见的论坛，回复基本只有“dddddddd”、“顶顶顶顶顶顶顶顶顶顶顶顶顶”、“啊上户口撒娇的两款黑色粉色的空间和对方”、“sghjsdkgdsvcssbnwe”这种东西。

如果论坛被这种东西盖满了，估计以后我也不会去看每一条回复，也不会有人想认真回复——因为我也看不懂。

如果你需要这些，大可以写个机器人，每天保证有几百万的这种回帖，可以极大满足你论坛活跃度的要求。

暂无计划

回复#4 @a543400 :

问题是你自己上网，你会看完一个网站随机推送的帖子或者上一个和下一个帖子吗？

反正我是不会，我要按自己兴趣从主页点开看。

监听鼠标移动事件然后根据坐标绘制一个浮层，思路在此，并不困难。

回复#2 @zangbob :

我觉得不像，那“不用看完一个贴又要返回首页才能看下一个”这句话也说不通。

回复#23 @b123456 :

下个版本加入，到时候跟其他模块整合在一起。

转发一段PHP之父 Rasmus Lerdorf 关于MVC的见解给你学习一番：

Q：如何规画网站架构，才会具有扩充性？

A：将一个网站应用，分成几十个独立小程式，前端透过 API提供服务，后端是应用程式引擎，这样做自然会有扩充性。因为应用的每一个部分，都有不同等级的使用方式，需要有不同的扩充程度（scaling level），需要不同的机制来处理。以开发Yahoo Mail而言，是要开发一个地址服务程式、一个读信服务、一个送信服务，而送信程式完全和读信程式无关。以Yahoo的规模而言，需

最开始就是MVC和大量__autoload，后来发现性能太菜，渲染一个页面竟然要超过10ms甚至要20ms，太丢人。

这样不就跟StartBBS之类的性能非常低下的BBS差不多了？

我就拆掉重写成这样了，OOP也是能不用尽量不用——因为代价巨大，特别是对于内存，大量使用OOP的话每个页面消耗的内存甚至可能超过1MiB。

如果首页和主题页面执行时间超过10ms，并且内存消耗超过1MiB，在目前这个量级下实在是非常丢人的一个数值。

目前就是Rewrite充当Controller，Model在根目录下，对应style里